home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group92c.txt
/
000113_icon-group-sender _Wed Dec 16 05:42:11 1992.msg
< prev
next >
Wrap
Internet Message Format
|
1993-01-04
|
2KB
Received: from owl.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 18 Dec 1992 10:02:03 MST
Received: by owl.cs.arizona.edu; Fri, 18 Dec 1992 10:02:02 MST
Date: 16 Dec 92 05:42:11 GMT
From: agate!spool.mu.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: Re: Iconc problem
Message-Id: <1992Dec16.054211.25548@midway.uchicago.edu>
References: <22111.724443467@porte-de-st-ouen.ics.uci.edu>
Sender: icon-group-request@cs.arizona.edu
To: icon-group@cs.arizona.edu
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
omalley@ics.uci.edu writes:
> I have a fairly large icon program that is showing some strange
>behavior. The program always works under the interpreter, but it
>doesn't under the compiler.
About half the time I use the compiler, programs bomb. It's a neat
system, but it's just not maintained the way the interpreter is, and
it's still somewhat experimental. The interpreter is really our
mainstay (sorta like for LISP and PROLOG programmers).
Try compiling your program with various Icon optimizations turned
off. Check the iconc man page on how to do this. When you figure
out what causes the problem, mail in a bug report to the Icon Pro-
ject (the usual - a test program that shows where the misbehavior
occurs, and a list of your platform and Icon implementation fea-
tures, along with a brief list of what you did when you built Icon
[i.e. did you use the standard configs, a prepacked binary, etc.?]).
--
-Richard L. Goerwitz goer%midway@uchicago.bitnet
goer@midway.uchicago.edu rutgers!oddjob!ellis!goer